Windows support: WSL boundary, working agent dispatch, doctor, sandbox badge, and CI that would have caught it - #465

…into coder/fork-windows-support-hardening-wsl-bound-e59f7d

…into coder/fork-windows-support-hardening-wsl-bound-a11a21

…into coder/fork-windows-support-hardening-wsl-bound-ab4875

…into coder/fork-windows-support-hardening-wsl-bound-93db45

Show whether the next run is actually confined (agent × repo location)
as a header badge. The resolver reports what we pass today: only Codex
is sandboxed (its default CLI sandbox); everyone else is an honest no.

On win32, projects.add runs four advisory checks (core.longpaths,
Git Bash, Node 22, WSL boundary) through the wrap seam and returns
them on the project. Failed checks never reject the add. Off win32
the doctor is a no-op.

The add-project modal lists what's wrong and what to do; Continue
dismisses it.

Add windows-latest to the test job so win32 paths stay honest. Make
npm scripts portable ( --prefix, --import for CODER_GROK_MCP_DISABLE )
instead of pinning the Windows job to bash.

Electron on win32 only runs the WSL contract: the rest of that suite
spawns shebang files as CODER_*_BIN, and CreateProcess will not
execute them. There is no node-pty in the repo, so a ConPTY rebuild
step would be a no-op.

Winget publishes an installer. package-cross.sh produces an unsigned
portable zip, not one — do not add a manifest that points at it.

…into coder/windows-support-hardening-wsl-boundary-d-d3d627

userData is a Windows path, so a WSL-side repo's worktree used to land
on the wrong filesystem — and git worktree add running inside the distro
cannot address a UNC. Park those worktrees next to the repo on ext4
(<repoParent>/.solenta/worktrees/<id>, or /tmp if the repo is on
/mnt/<drive>) and store the matching UNC so Windows-side existsSync
still works.

Git helpers now share one wrap: a WSL UNC cwd becomes wsl.exe --cd, and
UNC path args (worktree add/remove) are rewritten to the linux path.
Non-win32 behaviour is unchanged. No file watcher exists today;
status/diff are on-demand and PR refresh is already interval-polled.

Sequentially they stack three PROBE_TIMEOUT_MS waits, so a box with no
bash and no node froze the add dialog for 15s — on exactly the platform
the doctor exists for. The probes are independent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…into coder/windows-support-hardening-wsl-boundary-d-d3d627

…into coder/windows-support-hardening-wsl-boundary-d-d3d627

The win32 file list was written before the doctor and sandbox suites
existed — parallel workers could not see each other. All three new files
are pure resolvers or ssh.setExecFile fakes, so they run on Windows, and
they are precisely the win32 logic the matrix exists to keep honest.
Windows now runs 44 tests instead of 7.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Two unrelated-looking bugs in the same function.

1. isBinAvailable shelled out to `which`, which does not exist on Windows,
   so every provider failed "Provider binary not found" and nothing could
   be dispatched. win32 uses `where`, which prints every match in PATH
   order — take the first line. Only the local host is in question here:
   a project across a boundary returns early in assertProviderBinary,
   because the CLI lives on the other side. The cache key now includes the
   platform so a win32 miss cannot poison a posix hit.

2. That cache key held a raw NUL byte as its separator, which made `file`
   report providers.js as binary and made every plain `grep` of this file
   print nothing and exit 1 — indistinguishable from a real no-match. It
   has cost two sessions a wrong conclusion (#441). Now the \0 escape:
   same string, plain-text file.

Agent CLIs install on Windows as .cmd shims and Node refuses to exec
those. The six sites that spawn a provider binary go through cross-spawn,
which routes them via cmd.exe with correct escaping — necessary because
the prompt travels in argv, so hand-rolled quoting would be a correctness
and injection risk.

Not yet Windows-ready: /bin/sh in verify.js, `which node` in memory-sup,
and the SHELL default in pathEnv. Nothing here proves the app boots.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…into coder/fork-windows-support-hardening-wsl-bound-ea7084

# Conflicts:
#	src/components/ThreadView.tsx

…into coder/fork-windows-support-hardening-wsl-bound-4080d8

# Conflicts:
#	src/components/ThreadView.tsx

…into coder/fork-windows-support-hardening-wsl-bound-89b04f

# Conflicts:
#	src/components/ThreadView.tsx

Follow-up to #442. The four leftover POSIX-only spots now have a win32
path or an honest no-op, all testable on macOS by injecting the platform.

1. verify.js: Windows has no /bin/sh. Spawn Git Bash (`bash -c`) — the
   same POSIX shell the doctor already probes for. Verify commands are
   POSIX (`>&2`, `exit 3`); cmd.exe or PowerShell would silently
   mis-parse them. Missing bash is a real spawn error, not a fallback.
   A WSL-side project is wrapped through ssh.js so the command runs
   inside the distro. SSH remotes are left unwrapped: wrapping them
   would change macOS remote-verify behaviour.

2. memory-sup.js: `which node` is now providers.defaultWhich, so win32
   gets `where`. Two call sites, one existing helper; no new abstraction.

3. pathEnv.js: there is no login shell of the macOS/launchd kind on
   Windows. captureLoginPath and enrichProcessPath are explicit no-ops
   (source: "win32") instead of spawning /bin/zsh and failing closed.
   Also: do not split PATH on ':'. That would shred `C:\Windows\system32`.

4. devservers.js never used /bin/sh (argv is `npm run <script>`). It
   now goes through cross-spawn so npm.cmd works, wraps WSL-side roots
   the same way as verify, and kills the pid directly on win32 (no
   POSIX process group).

wrapCommand accepts an optional platform so WSL wrapping is testable
off Windows. Non-win32 behaviour is unchanged.

Nothing in CI has ever started the app on Windows, which is how a dead
dispatch path survived. smoke.js is already a full boot + IPC + fake-CLI
harness; it just could not run on win32.

resolveNodeBinary() now uses defaultWhich (where on win32, which
elsewhere) — same helper as #442. Fake CLIs stay shebang scripts so the
macOS path is unchanged. On win32 a sibling .cmd runs `node <script> %*`
and that path is what CODER_*_BIN points at, because CreateProcess will
not execute a shebang file and CODER_*_BIN must stay one executable
token (cross-spawn can launch the .cmd).

A new `smoke` job, separate from `npm test`, runs on macos-latest and
windows-latest after vite + core builds. npm run test:smoke is
`electron electron/smoke.js`. fail() already called app.exit(1); a
top-level uncaughtException handler was added because Electron stays
alive after "App threw an error during load", which would hang CI.

macOS: all five passes, exit 0. Missing dist: exit 1. Windows is
unverified until this job runs in CI.

…into coder/windows-support-hardening-wsl-boundary-d-d3d627

One writeFakeBin helper replaces 32 local shebang writers. POSIX still
writes the same #!/usr/bin/env node file. Win32 adds a .cmd wrapper
that cross-spawn can launch. The windows-latest list grows from 4
files / 44 tests to 21 / 238. gh and fm stay POSIX-only: they still
execFile the fake, which cannot run .cmd.

…into coder/windows-support-hardening-wsl-boundary-d-d3d627

Parallel workers landed one in electron/smoke.js and one in
electron/test/support/fakeBin.js. Same name, opposite rule for which
node the .cmd wrapper invokes: the test suite runs under plain node so
process.execPath is right there, smoke runs under Electron where it is
electron.exe and would boot a second Electron per fake. Both correct,
neither safe to copy into the other. Say so in both.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Two conflicts, both from the context-ring work (#317) landing on main
while this branch was open:

- ThreadView.tsx: git aligned the new SandboxBadge (#436) against main's
  rewritten ContextRingBadge. Both are kept — main's version of the ring
  already appears in full further down, so its side of the hunk was a
  duplicate.
- context-usage.test.js: main still had the local shebang writer; this
  branch migrated it to the shared writeFakeBin helper (#450).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>